Fix Symbol.info remapping in TreeTypeMap #23432
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #23279
The issue stems from the fact that in Inlining, when reassigning the owners the inlinined argument (with arg.changeOwner in paramBindingDef), due to a quirk in TypeTreeMap (fixed here), the info field of a
xa
symbol would not be completely remapped, referencing a TypeRef likedefn(correct Symbol, with newly remapped owner).Lifecycle(old and incorrect, with previous owner)
. This info would then be used intypedValDef
inerasure
to reassign the ValDefTypeTree
, referencing the old, incorrectSymbol
from now on. After that,LambdaLift
would remap the denotations of class and objectSymbols
found in the tree, while moving their trees outside of methods. Since no class or object definition referenced the old Symbol, that one would not get remapped. So by the time we generated backend code, theValDef
TypeTree would reference an incorrect location that no longer existed, causing the runtime error later.The reason why the TypeTreeMap was incorrect was because in situation like this:
The remapper would first copy and replace the outermost symbols (including lifecycle#7793, lifecycle#7794, defn#7795, defn#7796, xa#7797), and then separately go through classes definitions. Now we also remap
info
the second time, with the newly mapped nested Symbols.